Auto-creation of storage resource management paths

ABSTRACT

A method and an apparatus to automatically create storage resource management (SRM) paths has been presented. In one embodiment, the method includes monitoring a data storage system to collect configuration data of storage objects in the data storage system and automatically creating a storage resource management (SRM) path for a storage object in the data storage system using at least a portion of the configuration data in response to a user request to scan the storage object.

PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No.11/341,467, by Swartzlander et al., entitled “Auto-Creation of StorageResource Management Paths,” filed Jan. 27, 2006, which is incorporatedherein by reference.

TECHNICAL FIELD

Some embodiments of the present invention pertain to networked storagesystems, and more particularly to a method and apparatus forautomatically creating storage resource management (SRM) paths.

BACKGROUND

A storage appliance is a type of storage server which operates on behalfof one or more clients to store and manage shared data in a set of massstorage devices, such as magnetic or optical storage based disks. Themass storage devices are typically organized as one or more groups ofRedundant Array of Independent (or Inexpensive) Disks (RAID). Oneconfiguration in which storage appliances can be used is a networkattached storage (NAS) configuration. In a NAS configuration, a storageappliance can be implemented as a file server, or “filer” attached to anetwork, such as a local area network (LAN) or a corporate intranet. Anexample of such a storage appliance is any of the NetApp® Filer productsmade by Network Appliance, Inc. in Sunnyvale, Calif. Alternatively,storage appliances can be used in a storage area network (SAN)environment. A SAN is a highly efficient network of interconnected,shared storage devices. In a SAN, the storage appliance may provide aremote host with block-level access to stored data.

A filer may be coupled to a network and may serve as a storage devicefor several users, or clients, of the network. For example, the filermay store user directories and files for a corporate network or othernetwork, such as a LAN or a wide area network (WAN). Users of thenetwork can each be assigned an individual directory in which they canstore personal files. A user's directory can then be accessed fromcomputers coupled to the network.

A system administrator can maintain the filer, ensuring that the filercontinues to have adequate free space, that certain users are notmonopolizing storage on the filer, etc. A typical Multi-ApplianceManagement Application (MMA) can be used to monitor the storage on thefiler. An example of such an MMA is the DataFabric® Manager (DFM)products made by Network Appliance, Inc. in Sunnyvale, Calif. The MMAmay provide a Graphical User Interface (GUI) that allows theadministrator to more easily observe the condition of the filer.

Using some conventional MMAs, the administrator may schedule a scan of aspecific storage object on the filer to collect file-level informationand/or statistics. Storage objects are logical units of storage within asingle name space, such as a directory tree. One example of a storageobject is a volume. However, conventional MMAs typically requireadministrators to provide the directory path via which the storageobject is to be scanned. For large data storage systems maintained bymultiple administrators, each administrator may not know the directorypath of every storage object in the system. Furthermore, it isburdensome and inconvenient for the administrators to keep track of thecurrent directory paths of all storage objects in the system. As aresult, many administrators find the scanning tools provided by theseconventional MMAs difficult to use.

SUMMARY OF THE INVENTION

A method and an apparatus for automatically creating SRM paths aredisclosed. In one embodiment, the method includes monitoring a datastorage system to collect configuration data of storage objects in thedata storage system and automatically creating a storage resourcemanagement (SRM) path for a storage object in the data storage systemusing at least a portion of the configuration data in response to a userrequest to scan the storage object.

Other aspects of the invention will be apparent from the accompanyingfigures and from the detailed description which follows.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the present invention are illustrated by wayof example and not limitation in the figures of the accompanyingdrawings, in which like references indicate similar elements and inwhich:

FIG. 1 illustrates a monitoring system for a storage server;

FIG. 2 illustrates a block diagram of a server usable in someembodiments of the invention;

FIG. 3A illustrates one embodiment of a process to automatically createSRM paths;

FIG. 3B illustrates one embodiment of a process to monitor a datastorage system;

FIG. 4 illustrates one embodiment of a system to automatically createSRM paths in a data storage system; and

FIG. 5 illustrates one embodiment of a SAN.

DETAILED DESCRIPTION

Described herein are methods and apparatuses to automatically createstorage resource management (SRM) paths. Note that in this description,references to “one embodiment,” “an embodiment,” or other similarphrasing means that the feature being referred to is included in atleast one embodiment of the present invention. Further, such referencesdo not necessarily all refer to the same embodiment. Thus, the presentinvention can include a variety of combinations and/or integrations ofthe embodiments described herein.

According to an embodiment of the invention, a data storage system ismonitored to collect configuration data of storage objects in the datastorage system. When a user requests to scan one of the storage objects,a storage resource management (SRM) path for the storage object isautomatically created using at least a portion of the configurationdata, and therefore, relieving the user of the task of creating the SRMpath. Consequently, the user (e.g., system administrator) does not haveto be aware of the interconnections of the storage object to othercomponents (such as host agents) within the data storage system in orderto be able to initiate a scan of the storage object. Details of theabove terms will be discussed below with reference to variousembodiments of the present invention.

FIG. 1 illustrates a data storage system. In the current description, adata storage system refers to a group of computing devices and datastorage devices coupled to each other via a network to provide storageand management of data. The system 100 includes a storage appliance 102,a volume 118, an MMA 104, a database 108, a graphical user interface(GUI) 110, and two host agents 112 and 114. The storage appliance 102may be a filer. For the purpose of simplifying the illustration, only asingle storage appliance, i.e., the storage appliance 102, is shown inFIG. 1. However, the system 100 may include other storage appliances.The MMA 104, the database 108, and the GUI 110 may be implemented on asingle server. Alternatively, they may be implemented on separateservers and/or computers.

In one embodiment, the MMA 104 runs on an independent server and isresponsible for storage resource management (SRM). SRM includesmonitoring and management of storage resources within the system 100,such as, for example, applications, files, file systems, networks, etc.The MMA 104 may scan storage objects to collect information aboutstorage objects on (or managed by) the filer 102 to report back to asystem administrator by scanning the storage objects. To collectinformation about a storage object, the MMA 104 may recursively examinea directory path of the storage object for information about the storageobject (e.g., file-level statistics). As is well known in the relatedart, recursive examination involves the use of a procedure, subroutine,function, or algorithm that calls itself in a step having apredetermined termination condition so that successive repetitions ofthe procedure, subroutine, function, or algorithm are processed untilthe predetermined termination condition is met at which time the rest ofeach repetition is processed from the last one called to the first. Suchscanning is hereinafter referred to as a “path walk” (also known as“file walk” or “filewalk”).

Storage objects are logical units of storage within a single name space,such as a directory tree. One example of storage objects is a quota tree(also known as a “Qtree”). A Qtree is a top-level subdirectory (i.e.,the level of director immediately beneath a root of a directory tree),which has special properties for managing quotas. For example, a quotamay be set on a Qtree that limits to a total size of all files insidethe Qtree. In some cases, quotas are associated with users so that auser may not create files totaling more than a predetermined size.Another example of a storage object is a volume. In some embodiments, avolume is a logical data set that involves a group of storage devices(e.g., magnetic disks, optical disks, etc.), which may be assigned aname and be viewed as a file system. In some systems, a volume is thelargest unit of storage that contains a file system on a filer, such asthe volume 118 on the filer 102 in FIG. 1.

Some storage objects may be accessed via one or more shares, such asvolumes. A share is a set of data sets, such as files (also known as adirectory tree). In some data storage systems, a share may be assigned aname and made available to other components (e.g., storage appliances,servers, etc.) in the system through a data sharing protocol (e.g.,Common Internet File System (CIFS), Network File System (NFS), etc.).Alternatively, some storage objects may be directly accessed, such as astorage device having a logical unit number assigned (also referred toas a LUN).

In some embodiments, the storage appliance 102 is coupled to the volume118. The volume 118 may include one or more physical hard drives orremovable storage drives that comprise the storage for the storageappliance 102. For example, the volume 118 may comprise a RAIDstructure. The storage appliance 102 may also be coupled to additionalvolumes that comprise storage. In some instances, the volume 118 mayappear and function as a single entity even though the volume 118 maycontain several separate physical drives. As mentioned above, the volume118 may be viewed as a storage object on which a path walk can beperformed.

To perform a path walk on a storage object as defined above, the MMA 104may schedule the path walk and a host agent (e.g., the host agents 112and 114) may execute the path walk. In some embodiments, the host agent“walks” the specified directory path and gathers per-file and/orper-directory data. During the path walk, the MMA 104 may determine somecharacteristics of the files stored on the storage appliance 102.Examples of some characteristics of the files include the file names,size of the files, location of files, the location of directoriesrelative to each other, basic structure of a directory tree storedthereon, etc. These results can be accumulated, sorted, and stored in adatabase, where the administrator can later access them. The MMA 104 mayalso summarize the results of the path walk so that they are morereadable and more easily understood by the administrator.

Before performing path walks on storage objects, the MMA 104 mayperiodically monitor the system 100 to collect configuration data of thestorage objects. Configuration data of a storage object includesinformation on the setup of the storage object and interconnectionsbetween the storage object and other components within the data storagesystem 100, such as, for example, the host agent on which the storageobject is mounted, the shares through which the storage object isexported, etc. In one embodiment, the MMA 104 uses the configurationdata to create SRM paths for the storage objects.

In some embodiments, a SRM path of a storage object is a directory pathdefined to allow the gathering of file-level statistics of the storageobject, for example, the oldest files in the storage object, the largestfiles in the storage object, etc. In a large data storage systemmaintained by multiple administrators, it is difficult for everyadministrator to know the current SRM path of each storage object in thedata storage system. Thus, having the MMA 104 create a SRM path for astorage object automatically when an administrator requests a path walkon the storage object (more details of some embodiments of the MMA 104creating the SRM path are discussed below with reference to FIG. 4)relieves the administrators from keeping track of the SRM paths of allof the storage objects in the system, which could be an overwhelming andburdensome task. More details of some embodiments of the MMA 104creating the SRM path are discussed below with reference to FIG. 4.

After the MMA 104 has scheduled a path walk, the host agents 112 and 114may execute the path walk for the MMA 104. A host agent may beimplemented on an independent server. Storage appliances may be mountedon one or more host agents. For instance, the filer 102 is mounted onboth host agents 112 and 114. The host agents 112 and 114 may allow theMMA 104 to access the filer 102 in a secure and platform independentway. By having the host agents 112 and/or 114 to execute path walksrather than having the MMA 104 to execute path walks, the MMA 104 cansave its resources for other tasks, such as monitoring current activityon the filer 102. Moreover, multiple host agents can be added to thesystem 100 to perform a complete path walk in less time.

According to one embodiment of the invention, the host agents 112 and114 may use different file sharing protocols. For example, the hostagent 112 uses CIFS, while the host agent 114 uses NFS. In someembodiments, the host agent 112 is coupled to storage 116 to store theresults of a path walk while the path walk is still in progress andbefore the results are transferred to the MMA 104. The host agent 114may or may not be coupled to any storage for this purpose.

The results of a path walk may be transferred to and stored on thedatabase server 108 after the path walk is complete. The database server108 can then be accessed by the GUI 110, so that system administratorcan search the results of the path walk. Through the GUI 110, theadministrator may perform various tasks, such as parsing the results ofa specific file walk and monitoring the total size of files stored onthe filer 102, the size of particular directories and theirsubdirectories, the parents of specific directories, etc. According toone embodiment, the GUI 110 may be a web-based Java application.

FIG. 2 illustrates a block diagram of a server 1040 usable in someembodiments to run the MMA 104. The server 1040 includes a processor202, a memory 204, and a network adapter 206. These components arelinked through a bus system 230, which may include one or more physicalbuses and/or controllers, bridges, etc. Note that the server 1040 mayhave different configurations in different embodiments. Moreover, theserver 1040 may include more or less components than those shown in FIG.2.

The processor 202 may be any appropriate microprocessor or centralprocessing unit (CPU). The memory 204 may include a main random accessmemory (RAM), as well as other memories including read only memories(ROM), flash memories, etc. The operating system 212 is stored in thememory 204. The operating system 212 may be any computer operatingsystem, such as a UNIX or Windows based system. The network adapter 206allows the server 1040 to communicate with remote computers over thenetwork 214. For example, the server 1040 may send data to the database108 via the network 214 in some embodiments. The server 1040 may alsocommunicate with host agents 112 and 114 via the network 214.

FIG. 3A illustrates one embodiment of a process to automatically createSRM paths in a data storage system. The process may be performed byprocessing logic that may comprise hardware (e.g., circuitry, dedicatedlogic, etc.), software (such as a program operable to run on ageneral-purpose computer system or a dedicated machine), firmware, or acombination of any of the above.

In one embodiment, configuration data of storage objects within thesystem may change over time. Thus, processing logic periodically monitora data storage system in order to update its knowledge of the currentconfiguration of storage objects within the system (processing block310). To periodically monitor the data storage system, processing logicmay check the configuration of the data storage system at regular timeintervals. Processing logic may collect configuration data of variousstorage objects within the data storage system in order to prepare forcreating SRM paths for the storage objects. To collect configurationdata of a storage object, processing logic may recursively examine thedirectory path of the storage object to gather configuration data of thestorage object. As discussed above, configuration data of a storageobject includes information on the setup and connection of the storageobject within the data storage system. More details of processing block310 are discussed below with reference to FIG. 3B.

Processing logic checks whether a user (such as a system administrator)requests to scan any of the storage objects (processing block 320). Ifno user request is received, processing logic returns to processingblock 310 to repeat the periodic monitoring of the data storage system.Otherwise, processing logic creates a SRM path for the storage object inresponse to the user request (processing block 323). To create the SRMpath for the storage object, processing logic generates a directory pathvia which the storage object may be accessed in order to be scanned,where the directory path may include a drive name assigned to thestorage object, names of folders within which the storage objectresides, names of shares through which the storage object is exported,etc. In some embodiments, processing logic uses the configuration datacollected to put together a SRM path for the storage object. Forinstance, processing logic may use a mount and a share discovered duringthe periodic monitoring to create the directory path corresponding tothe storage object. Via the SRM path created, processing logic thenscans the storage object to service the user request (processing block325).

FIG. 3B illustrates one embodiment of a process to periodically monitora data storage system, such as in block 310.

In one embodiment, processing logic monitors host agents in the datastorage system to determine which storage objects are mounted on whichhost agents (processing block 312). Note that multiple storage objectsmay be mounted on a single host agent, and likewise, a single storageobject may be mounted on multiple host agents, such as the storageobjects on the filer 102 in FIG. 1. Processing logic discovers sharesthrough which the storage objects are exported (processing block 314).In some embodiments, a share is a set of data sets, such as files (alsoknown as directory tree), which is assigned a name and is made availableto other components in the system through a data sharing protocol (e.g.,CIFS, NFS, etc.). The shares may include NFS shares and/or CIFS sharesfor example. Processing logic then updates configuration data, such asthe mounts and the shares determined above, in an appropriate datastructure or structures, such as a NFS export table, a CIFS sharestable, etc. (processing block 316). In one embodiment, these tables maybe stored in a storage device within a server running a MMA (e.g., theserver 1040 in FIG. 2). Details of some embodiments of the monitordatabase are discussed below with reference to FIG. 4.

After updating the monitor database, processing logic waits apredetermined period of time, such as 30 minutes (processing block 318).Then processing logic transitions back to processing block 312 afterwaiting the predetermined period of time to repeat the processing blocks312-318 to monitor the data storage system. In some embodiments, thepredetermined period of time may be set by a user with administrativeprivileges during initial setup of the data storage system.Alternatively, a default period of time may be used. Moreover, userswith administrative privileges may modify the period of time later.

FIG. 4 illustrates one embodiment of a system to automatically createSRM paths in a data storage system. The system 400 includes a server4100, a storage appliance 420, storage devices 425, and a host agent430. The server 4100 is coupled to the storage appliance 420 and thehost agent 430. Note that there may be multiple storage appliances andhost agents coupled to the server 4100. However, to simplifydescription, only one storage appliance and one host agent are shown inFIG. 4.

In some embodiments, the storage appliance 420 includes a filer. Thestorage appliance 420 may be coupled to some storage devices 425, suchas magnetic disks, optical drives, etc. The storage devices 425 may beorganized into volumes and be accessed through the storage appliance420. The storage appliance 420 may be further coupled to the host agent430. The host agent 430 may have a UNIX operating system, a Linuxoperating system, a Windows operating system, etc.

In one embodiment, the server 4100 includes a MMA module 4110, a monitordatabase 4120, and a user interface module 4130. The MMA module 4110 islogically coupled to the monitor database 4120, which is furtherlogically coupled to the user interface module 4130. The MMA module 4110includes a storage resource management monitor module 4114 and aShareMon module 4112. The storage resource management monitor module4114 is a module to monitor data resources within the system 400. Insome embodiments, the storage resource management monitor module 4114periodically monitors the NFS mounts in host agent 430 having a UNIX orLinux operating system. In some embodiments, the ShareMon module 4112discovers shares through which storage objects of the storage appliance420 are exported. In one embodiment, the storage appliance 420 exportsdetails about the shares through application programming interface(APIs). The ShareMon module 4112 uses these APIs to retrieve the detailsabout the shares and store the details in one or more tables in theMonitor Database 4120. The shares may include NFS shares if the storageappliance 420 is accessed through a UNIX or Linux operating system.Alternatively, the shares may include CIFS shares if the storageappliance 420 is accessed through a Windows operating system. In otherembodiments, the host agent 430 may implement an operating system otherthan the above mentioned operating systems to access the storageappliance 420.

As mentioned above, the MMA module 4110 is coupled to the monitordatabase 4120. The monitor database 4120 stores configuration data ofthe data storage system 400. In one embodiment, the monitor database4120 includes various tables to store the configuration data, such as aLUN path table 4121, a NFS exports table 4123, a CIFS shares table 4125,a SRM file system table 4127, a Hosts table 4128, and a SRM links table4129. In some embodiments, the storage resource management monitormodule 4114 updates the SRM file system table 4127 with the current NFSmounts in the host agent 430. Both the device name and the path name ofeach NFS mount may be stored in the SRM file system table 4127. In someembodiments, the ShareMon module 4112 updates the NFS exports table 4123with NFS shares discovered. Moreover; the ShareMon module 4112 mayupdate the CIFS shares table 4125 with CIFS shares discovered. In someembodiments, the SRM links table 4129 stores the mapping between thestorage objects and SRM paths. The SRM links table 4129 may contain aSRM path identification (ID) and a Storage Object ID for each mapping.In some embodiments, LUN exports may be stored in the LUN paths table4121.

To further illustrate the above concept, consider the following example.Suppose the NFS exports table 4123 has the following entries for astorage appliance, “Filer1”:

Storage Appliance NFS Exports Filer1 /vol/vol1 Filer1 vol/vol2

Further suppose that the CIFS shares table 4125 stores the followingentries for another storage appliance, “Filer2”:

Storage Appliance CIFS share Path Filer2 csvol3 /vol/vol3 Filer2 csvol4/vol/vol4

In addition, the SRM file systems table 4127 has the following entries:

Agent Device Name Path Name HostAgentI /mntvol1 /vol/vol1 HostAgentI/mntvol2 /vol/vol2

Moreover, the Hosts table 4128 as shown in FIG. 4 has a list of hostagents in the system, including HostAgentl and HostAgent2 in the currentexample. HostAgentl is a UNIX host agent and HostAgent2 is a Windowshost agent.

In one case, a user requests to perform a path walk on the storageobject, /vol/vol1. In response to the user's request, the MMA module4110 finds the device name for /vol/vol1 using the SRM file systemstable 4127. According to the first entry in the SRM file systems table4127 above, the device name corresponding to the storage object/vol/voll is /mntvol1. Therefore, the SRM path created for the storageobject vol/vol1 is HostAgentl:/mntvol1. HostAgentl is able to accessFiler1 using NFS protocol.

In another case, the user requests to perform a path walk on the storageobject /vol/vol3. The MMA module 4110 uses the information from the CIFSshares table 4125 to determine that the storage object /vol/vol3 may beaccessed through the CIFS share csvol3 and the storage object /vol/vol3is on the storage appliance Filer2. The MMA module 4110 goes througheach Windows host agent in the Hosts table 4128 and verifies if theWindow host agent can access the storage object /vol/vol3 using the CIFSshare csvol3. As soon as the MMA module 4110 finds a Windows host agentthat can access the storage object /vol/vol3 using the CIFS sharecsvol3, which is HostAgent2 in the current example, the MMA module 4110creates the SRM path for /vol/vol3 using the host agent's name, thestorage appliance's name, and the CIFS share's name. In the currentexample, the SRM path created for /vol/vol3 isHostAgent2:\\Filer2\csvol3.

In some embodiments, the MMA Module 4110 updates the SRM links table4129 to store the mapping between the storage objects, /vol/vol1 and/vol/vol3, and their corresponding SRM paths. The updated SRM linkstable 4129 includes the following entries:

Storage Object SRM Path Filer1:/vol/vol1 HostAgentI:/mntvol1Filer2:/vol/vol3 HostAgent2:\\Filer2\csvol3

Referring to FIG. 4, the monitor database 4120 resides within the server4100. Alternatively, the monitor database 4120 may reside on a datastorage device external to the server 4100. As mentioned above, themonitor database 4120 is further coupled to the user interface module4130.

In one embodiment, the user interface module 4130 includes a graphicaluser interface module 4131 and a command line interface module 4133. Thegraphical user interface module 4131 may include a web graphical userinterface module operable to interact with a web browser on a clientcomputing device (e.g., a personal computer, a workstation, etc.)coupled to the server 4100. Alternatively, a user may access the commandline interface module 4133 using telnet from a client computing devicecoupled to the server 4100. The client computing device may be coupledto the server 4100 wirelessly or via wirelines. Moreover, the clientcomputing device may locate at the same physical location as the server4100 or at a different physical location from the server 4100.

Many of the techniques introduced above have been described in thecontext of a network-attached storage (NAS) environment. However, thesetechniques can also be applied in various other contexts. For example,the techniques introduced above can be applied in a storage area network(SAN) environment. A SAN is a highly efficient network ofinterconnected, shared storage devices. One difference between NAS andSAN is that in a SAN, the storage server (which may be an appliance)provides a remote host with block-level access to stored data, whereasin a NAS configuration, the storage server provides clients withfile-level access to stored data. For example, the SRM path creationtechniques described above may be applied to LUNs in SAN.

FIG. 5 illustrates one embodiment of a SAN. The SAN 500 includes aserver 5100 coupled to a storage appliance 520 and a host agent 530. Thestorage appliance 520 is also referred to as a SAN host. Note that theremay be multiple storage appliances and/or host agents in the SAN, butonly one storage appliance 520 and one host agent 530 are shown in FIG.5 to avoid obscuring the view of the illustration. A number of storageobjects 525 with logical unit numbers assigned to them are on thestorage appliance 520. The storage objects 525 are also referred to asLUNs. In the server 5100, a MMA module 5110 includes a LUN monitor 5112,which records the names of the LUNs on the storage appliance 520. TheMMA module 5110 further includes a SAN host monitor 5114 to record whichLUNs 525 are mounted on which storage appliance 520. Each storageappliance 520 is coupled to a host agent 530. For each of the LUNs 525,the path to the LUN (which may include a drive letter if the operatingsystem on the storage appliance on which the LUN is found is Windows).The host agent 530 may further determine the name of the LUN using aSmall Computer System Interface (“SCSI”) pass-through command. Whenthere is a request to create an SRM path for a LUN, the MMA module 5110goes through the LUN paths table 5121 to find a LUN having a namematching the name of the LUN requested. The host agent and the path nameof the LUN with the matching name are used to create the SRM path forthe LUN requested. If no LUN is found that matches the name of the LUNrequested, the operation fails.

This invention has been described with reference to specific exemplaryembodiments thereof. It will, however, be evident to persons having thebenefit of this disclosure that various modifications and changes may bemade to these embodiments without departing from the broader spirit andscope of the invention. The specification and drawings are accordinglyto be regarded in an illustrative, rather than in a restrictive sense.

1. A method comprising: monitoring, by a server implementing amulti-appliance management application (MMA), a data storage system tocollect configuration data of a plurality of storage objects in the datastorage system, wherein the server includes a processor and a memory;receiving, by the MMA, a request to execute a traversal on a givenstorage object of the plurality of storage objects in the data storagesystem; prior to executing the traversal, creating by the MMA anidentification of a storage resource management (SRM) path for the givenstorage object using at least a portion of the configuration data,wherein the MMA stores the identification of the SRM path in the serverimplementing the MMA, and wherein the SRM path includes an identity of ahost agent that is coupled between the server implementing the MMA andthe given storage object; and executing the traversal, by the MMA, onthe given storage object by utilizing the identification of the SRMpath.
 2. The method of claim 1, wherein the MMA stores a mapping of anidentification of the given storage object to the identification of theSRM path.
 3. The method of claim 1, wherein the MMA stores the identityof the host agent and a directory path associated with the SRM path inan SRM data structure associated with the server.
 4. The method of claim1, wherein monitoring the data storage system comprises: periodicallymonitoring a plurality of host agents on which the plurality of storageobjects are mounted; and identifying shares through which the pluralityof storage objects are exported.
 5. The method of claim 4, whereinperiodically monitoring the plurality of host agents comprisesperiodically monitoring one or more Network File System (NFS) exportsmounted on one or more of the plurality of host agents.
 6. The method ofclaim 4, wherein periodically monitoring the plurality of host agentscomprises testing whether at least one of the plurality of host agentscan access a Common Internet File System (CIFS) share.
 7. The method ofclaim 4, wherein the plurality of storage objects are managed by astorage appliance coupled to the plurality of host agents, andmonitoring the data storage system further comprises accessing thestorage appliance via a network.
 8. The method of claim 1, furthercomprising: storing the configuration data in a monitor database; andretrieving at least a portion of the configuration data from the monitordatabase in response to the user request to execute a traversal on thegiven storage object.
 9. A server comprising: a processor; a monitordatabase to store configuration data associated with a plurality ofstorage objects in a data storage system; and a management applicationto: receive a request to execute a traversal on a given storage objectof the plurality of storage objects in the data storage system; createan identification of an storage resource management (SRM) path for thegiven storage object using at least a portion of the configuration datain the monitor database, wherein the SRM path includes an identity of ahost agent that is coupled between the server and the storage object;and execute the traversal on the given storage object by utilizing theidentification of the SRM path.
 10. The server of claim 9, furthercomprising: An SRM monitor to periodically monitor mounts of theplurality of storage objects and to update configuration datacorresponding to the mounts in the monitor database; and a share monitorcoupled to the SRM monitor to discover shares through which theplurality of storage objects are exported and to update configurationdata corresponding to the shares in the monitor database; and
 11. Theserver of claim 9, wherein the management application is furtherconfigured to: store a mapping of an identification of the given storageobject to the identification of the SRM path.
 12. The server of claim 9,wherein the management application is further configured to: store theidentity of the host agent and a directory path associated with the SRMpath in an SRM data structure associated with the server.
 13. A datastorage system comprising: a processor; a user interface module; aplurality of storage objects; a monitor datastore coupled to the userinterface module for periodically monitoring the data storage system tocollect configuration data of the plurality of storage objects in thedata storage system; and a multi-appliance management application (MMA)module coupled to the monitor database and to the plurality of storageobjects, the MMA module configured to: receive a request, via the userinterface module, to execute a traversal on a given storage object ofthe plurality of storage objects in the data storage system; prior toexecuting the traversal, create an identification of a storage resourcemanagement (SRM) path for the given storage object using at least aportion of the configuration data, wherein the MMA stores theidentification of the SRM path in the server implementing the MMA,wherein the SRM path includes an identity of a host agent that iscoupled between the server implementing the MMA and the given storageobject; and execute the traversal on the given storage object byutilizing the identification of the SRM path.
 14. The system of claim13, wherein the monitor database includes a first data structure tostore mappings between the plurality of storage objects and acorresponding plurality of SRM paths.
 15. The system of claim 13,wherein the monitor database includes a second data structure to store aplurality of NFS shares associated with the plurality of storage objectsin the data storage system.
 16. The system of claim 13, furthercomprising a plurality of host agents coupled to the plurality ofstorage objects, wherein the monitor database includes a third datastructure to store information on NFS shares mounted on the plurality ofhost agents.
 17. The system of claim 13, wherein the monitor databaseincludes a fourth data structure to store a plurality of CIFS sharesassociated with the plurality of storage objects in the data storagesystem.
 18. The system of claim 13, wherein the user interface moduleincludes a command line interface module.
 19. The system of claim 13,wherein the user interface module includes a graphical user interfacemodule.
 20. The method of claim 13, wherein the MMA stores a mapping ofan identification of the given storage object to the identification ofthe SRM path.
 21. The method of claim 13, wherein the MMA stores theidentity of the host agent and a directory path associated with the SRMpath in an SRM file system associated with the server.